One of the most significant problems faced by designers of electronic systems, particularly digital systems, is meeting the demand for greater speed, complexity and functionality. At the same time, the digital system designer must ensure that the design will be as reliable as possible, and that it can be produced as quickly as possible. These pressures are fueled by recent advances in semiconductor technology which make possible the design of extremely fast integrated circuit (IC) chips having literally millions of transistors in relatively small packages. The added fact that these newer high-density integrated circuits often draw considerably less power than their less dense predecessors makes them all the more attractive to potential users (e.g., for high-functionality, portable, battery-operated devices such as notebook computers and other battery powered, portable equipment).
In producing large, high-complexity electronic systems which incorporate new integrated circuit designs, particularly semi-custom ASICs (Application Specific Integrated Circuits), there are essentially a number of separate designs occurring at a number of different levels of abstraction. For example, in a typical electronic system which incorporates one or more new ASIC designs, it is necessary to specify the design of the systems and to specify the design(s) of the ASIC(s). Many of the ASIC design choices are based upon and derived from higher-level design choices made in the specification of the system design.
It is well established and understood by those of ordinary skill in the art that as the complexity of an integrated circuit (e.g., ASIC) design increases, so does the difficulty of ensuring the "correctness" of the design. Modern simulation tools aid considerably in verifying the function of a digital integrated circuit, but verifying the behavior of a system design which includes one or more such integrated circuit designs is considerably more complicated.
Recent studies have shown that roughly 50% of all digital systems designed fail to function correctly the first time. By way of contrast, the first-time success rate for ASICs alone is considerably higher. With complicated electronic system designs, ASIC designers can often become engrossed in the lower-level ASIC design issues and can miss important system-related design issues. In effect, the designer is often unable to "see the forest for the trees". Conversely, when working on the system-level design, it is often difficult to anticipate the effect of system-level design choices on the lower levels of the design. As a result, perfectly functional ASIC designs may be produced which fail to perform properly when interconnected as an electronic system.
One of the main reasons for this relatively higher rate of system design failure is that today's design methodologies typically rely on "perfect" design specification which must completely and accurately specify the design of an electronic system. Often times the specification is written on paper in a natural (non-formal) language (i.e., written in an ad hoc fashion using plain language, e.g., English), and there are no tools to help the system designer ascertain the correctness or completeness of the specification until quite late in the implementation stage.
Further, the use of non-formal language for a system specification introduces the possibility of inconsistencies and ambiguities. The peculiarities of the specification writer's phrasing of the specification can lead to misinterpretation by others, ultimately resulting in unintended or unanticipated system behavior.
Often, it may become apparent during the design of one of the lower-level portions (subsystems) of an electronic system (e.g., an ASIC or a portion thereof) that system-level design choices have created unanticipated lower-level technical problems. As a result, a different lower-level approach is chosen, necessitating a change in the overall system design. It is often difficult to ensure that changes made in this manner will not affect the overall behavior of the system.
Even when a design seems to proceed smoothly, requiring no system-level changes, and where all subsystems perform "successfully" according to their respective lower-level specifications, unanticipated and unspecified peculiarities of the subsystems can interact in unexpected ways to cause improper system behavior. This is especially troublesome when the improper behavior occurs only under conditions which occur infrequently, since such conditions are often difficult to anticipate and/or to test.
Often, after a portion of the design and/or implementation of the system, it may be discovered that something was overlooked in the initial specification. If the oversight is discovered early enough in the design process, it may be possible to simply revise the specification. More often, however, it is necessary to iterate at least a portion of both the specification and the design process. Depending upon how late in the design process the problem is discovered, this can impose significant delays in time, and significant additional costs to the design process.
Many of the problems associated with producing large, complicated "first-time-right" circuits and systems arise from the automated design methodologies presently in use. These methodologies are quite good at eliminating repetitive and tedious manual operations, but often perform poorly with respect to higher-level design integrity.
Present day state-of-the-art design technique, logic synthesis, is really only a mapping between different levels of physical abstraction.
One of the most difficult problems in design automation is the inability to get timing closure at even the gate level effectively. This forces designers to do two designs: logic design and timing design. Otherwise, the designer simply over-designs the circuits, because the best case timing is much different from the worst case timing. In other cases, designers insist on control of device layout so that they can evaluate all of the tradeoffs between implementation and timing.
Present computer aided design (CAD) systems for the design of electronic circuits, referred to as ECAD or Electronic CAD systems, assist in the design of electronic circuits by providing a user with a set of software tools running on a digital computer with a graphical display device. Typically, five major software program functions run on the ECAD system: a schematic editor, a logic compiler, a logic simulator, a logic verifier, and a layout program. The schematic editor program allows the user of the system to enter and/or modify a schematic diagram using the display screen, generating a net list (summary of connections between components) in the process. The logic compiler takes the net list as an input, and using a component database puts all of the information necessary for layout, verification and simulation into a schematic object file or files whose format(s) is(are) optimized specifically for those functions. The logic verifier checks the schematic for design errors, such as multiple outputs connected together, overloaded signal paths, etc., and generates error indications if any such design problems exist. The logic simulator takes the schematic object file(s) and simulation models, and generates a set of simulation results, acting on instructions, initial conditions and input signal values provided to it either in the form of a file or user input. The layout program generates data from which a semiconductor chip (or a circuit board) may be laid out and produced.
The Modular Design Environment (MDE) produced by LSI Logic Corporation of Milpitas, Calif., is a suite of software tools for computers running the UNIX operating system. MDE comprises a schematic editor (LSED) and a simulator (LDS), among other software programs, and provides an example of commercially available tools of the aforementioned type. Another example of a schematic editor, schematic compiler, and schematic simulator may be found in the SCALDstation produced by Valid Logic Systems, Inc. of Mountain View, Calif.
VHDL, or VHSIC (Very High Speed Integrated Circuit) Hardware Description Language, is a recently developed, higher level language for describing complex devices. The form of a VHDL description is described by means of a context-free syntax together with context-dependent syntactic and semantic requirements expressed by narrative rules. VHDL is described in IEEE Standard VHDL Language Reference Manual (IEEE Std 1076-1987), and is also known as MIL-STD-454, Regulation 64.
VHDL represents an important step forward in design specification languages because the semantics, or intent, of the language constructs are clearly specified. In theory, VHDL unambiguously describes a designer's intended system or circuit behavior, in syntactic terms. The "design entity" is the primary hardware abstraction in VHDL. It represents a portion of a hardware design that has well-defined inputs and outputs and performs a well-defined function. A design entity may represent an entire system, a sub-system, a board, a chip, a macro-cell, a logic gate, or any level of abstraction in between. A "configuration" can be used to describe how design entities are put together to form a complete design.
VHDL supports three distinct styles for the description of hardware architectures. The first of these is "structural" description, wherein the architecture is expressed as a hierarchical arrangement of interconnected components. The second style is "data-flow" description, in which the architecture is broken down into a set of concurrent register assignments, each of which may be under the control of gating signals. This description subsumes the style of description embodied in register transfer level (RTL) descriptions. The third style is "behavioral" description, wherein the design is described in sequential program statements similar to a high-level programming language. In the main description hereinafter, the behavioral description style is discussed. However, all three styles may be intermixed in a single architecture.
A methodology for deriving a lower-level, physically-implementable description, such as a RTL description of the higher level (e.g., VHDL) description, via an intermediate rule-based tool such as Prolog, is disclosed herein.
Prolog is a programming language based on predicate logic. It can be used for "intelligent" tasks like mathematical theorem proving. A Prolog program is a set of rules which define the relationships among objects. The general form of a Prolog rule is a "horn" clause, in which a specified "goal" is true if certain conditions are true. Execution of a Prolog program involves finding a proof for the goal in question, using unification and resolution. An important aspect of Prolog employed in the present invention is "term.sub.-- expansion", which converts predefined rules into ordinary Prolog clauses.